C5 — 网页 AI 工具矩阵工厂 · 场景指引

core-C5 auto-ops 调度总压测 T1/T2/T3 三阶段   版本：2026-09-27  |  故事卡：stories/core-C5-网页AI工具批量设计.md

一、场景概述

C5 场景模拟一位独立开发者（"工厂主"）利用 AI 流水线批量制造 20 至 40 个单页小工具（如 JSON 格式化器、图片压缩器、二维码生成器、PDF 转换器、文本清洗器等），这些工具共用一套统一外壳与账号体系，通过搜索引擎优化（SEO）与目录站导流获取自然流量，最终通过 Google AdSense 广告与 Pro 版一次性付费实现变现。这个场景的核心矛盾并非产品设计或市场策略，而是平台的并发轮次调度与算力/预算分配机制能否真正扛住高并发、长周期的压力测试。

本场景是六张核心故事卡中对 auto-ops 时间片轮次调度 压测最重的一张。在 T3 规模化阶段，项目将同时维护 30 个在线工具，对应 30+ 并行任务队列，每个任务拥有独立的优先级、权重与时间片配额。调度器需要在每一轮（tick）中根据权重分配算法从任务池中选出本轮的执行组合，同时保证高优先级任务不被低优先级任务"饿死"——即长期得不到执行资源。当所有待办任务处理完毕后，系统进入 free 维护模式，此时调度器不应误停仍在建设中的任务，这是一个看似简单但在工程实现上极易出错的边界条件。

权重分配算法是本场景的核心机制之一。每个任务被赋予一个权重值（如 1/2/3），权重越高，在轮次调度中被选中的概率越大。然而，权重机制必须与"公平性保障"并行运作：即便某任务权重为 1（最低），也不能出现其连续 5 轮以上未被选中的情况——这就是所谓的"饿死判定"。T1-D1 首跑数据已经揭示了一个关键事实：在 68 轮调度中，同权重（w=1）的三个任务实际被选中次数分别为 3、5、14，差异高达 4.7 倍，且全部 5 条在跑任务都命中了"连续 5 轮以上未被选中"的饿死条件。这一发现直接指向了 ISSUE-W4-45 中记录的槽位序与空槽重定向机制的公平性缺陷。

review 重排是另一个关键机制。系统每隔 N 轮（由 review_every_rounds 配置，典型值为 6）自动进入一次 review 模式，在此模式下，调度器会重新评估所有任务的优先级与权重分配，根据最新的业务数据（如 RPM、流量、收录情况）进行动态调整。例如，一个 RPM 持续走低的工具应当被降权甚至砍掉，而流量表现优异的工具应当获得更多算力投入。review 轮本身也会产生 LLM 调用成本（T1-D1 数据显示 11 个 review 轮中有 7 个失败，主因是 invalid_xml，对应 FIX-018 待修复项）。

失败分级降级→升级→退出兜底构成了任务生命周期的完整闭环。当一个任务在某轮执行中失败时，系统首先进行降级处理（如降低优先级、减少资源配额）；如果连续多轮失败，则升级为更高级别的告警，通知管理者 Agent 介入决策；当失败次数超过阈值（如验收拒绝次数达到 4 次），系统触发"兜底暂停"机制，将整个项目暂停以防止无效消耗预算。T1-D1 测试中，T5 任务因验收被拒 4 次触发了 acceptance_reject_limit 兜底暂停（ISSUE-W4-46），导致整个项目在 15:37:46 被自动停摆，这一事件虽然暴露了兜底机制的有效性，但也揭示了兜底态下 UI "停止"按钮置灰、收口通道不可达的次生问题。

预算抢占不饿死是本场景的另一个关键约束。在 30 个任务同时争抢有限预算的场景下，必须保证没有单个任务能够吃满全部预算，也不能因为某个任务预算超支而导致其他在建任务被连带暂停。当前的预算控制机制是项目级的（BudgetController 以 projectID 为键），尚无任务级预算配额的实现。这意味着当单轮预算超过 single_round_max_budget（本场景设为 6 元）时，系统会暂停整个项目而非仅仅暂停超额任务——这是 T3 规模化压测中必须重点验证和记录的行为特征。

二、场景目标与主战场能力

C5 场景的主战场能力可以归纳为三大维度：SEO/营销自动化、调度公平性和坪效分析。这三个维度分别对应了工具矩阵工厂的业务增长引擎、平台调度基础设施的健康度、以及长期可持续运营的经济性验证。

2.1 SEO/营销自动化

工具矩阵的流量获取完全依赖 SEO 与内容营销，不投入广告预算。AI 系统需要自动完成以下全链路：关键词调研（通过 Agent 引擎调用搜索 API）→ 关键词排序与分配（根据搜索量、竞争度分配到具体工具）→ 内容生成（loop 引擎驱动 qianshou 子进程编写工具页面代码）→ 部署上线（通过 deploy 模块发布到 mail1 增量目录）→ sitemap 提交 → 持续的内容更新与内链优化。

在 T1 阶段，系统需要完成 3 个基础工具的上线并争取被 Google 收录。T2 阶段扩展到 15 个工具，此时需要批量内链与合集页来增强站点权重。T3 阶段达到 30 个工具，需要跨工具推荐位、竞品监控以及数据驱动的长尾淘汰机制。整个过程中，外部事件流（GSC 收录周报、AdSense 收益、流量脉冲等）驱动内容任务的自动创建与优先级调整，形成"数据→决策→执行→反馈"的闭环。

营销自动化还包括社媒导流帖的生成与发布。系统需要根据每个工具的特点自动生成适合 Hacker News、Reddit、Twitter 等平台发布的导流文案，这些文案经过人工审批后通过连接器发布。FIX-002 待 e2e 验证前，所有导流帖停留在 pending_review 状态，脉冲流量事件改为人工注入模式。

2.2 调度公平性

调度公平性是本场景的王牌断言，也是区别于其他五张故事卡的核心特色。在 20+ 任务并行的场景下，调度器必须保证每个任务都能获得与其权重相匹配的执行机会，同时不能出现任何任务被"饿死"（长期得不到执行资源）的情况。

公平性的量化判定依赖以下核心指标：

• 同权重实得轮数比：相同权重的任务，其实际被选中执行的轮次应当大致相等。T1-D1 数据显示同权重（w=1）任务实得轮数差达 4.7 倍，远超可接受范围。
• 饿死判定：任何任务不得连续 5 轮未被选中。在轮次间隔约 60-110 秒的机制下，5 轮未选中意味着 5-9 分钟墙钟时间内该任务完全停滞。T1-D1 中 5/5 条在跑任务全部命中此条件，最长等待达 18 轮。
• 空槽重定向份额：当高权重任务完成或空闲时，其时间片应当被公平地重新分配给其他任务。T1-D1 的份额预测模型（30/30/10/10/20%）与实测值（27.5/29.4/5.9/9.8/21.6%）基本吻合，说明空槽重定向机制在工作但分配比例存在偏差。
• 优先级不插队：高优先级任务不应持续抢占低优先级任务的时间片，导致后者饿死。

由于"调度可观测面板"（P0 建议项）尚未落地，本场景的公平性判定目前依赖 psql 离线计算：从 auto_ops_rounds 表提取轮次-任务矩阵，按窗口统计每个任务被选中的频次与最长等待轮数，生成饿死统计表由 harness 每日贴入 daily 报告。这一取证方式虽然可行，但效率较低且不够直观，是后续产品改进的重要方向。

2.3 坪效分析

坪效（收入/维护成本）是衡量每个工具经济可行性的核心指标。在 T3 阶段，系统需要能够按工具维度计算坪效，并据此进行长尾淘汰决策。具体而言，每个工具的研发成本（token 消耗）、维护成本（每轮调度分配的时间片）与收入（AdSense RPM × 流量）需要可追溯、可对比。

当前坪效分析面临的主要瓶颈是 FIX-006（计费明细页缺失）：单工具成本与坪效只能依赖 amoeba 模块与 SQL 手算。T1-D1 的实测数据显示，loop 引擎单价（约 0.0554 元/轮）是 Agent 引擎单价（约 0.0059 元/轮）的 9.4 倍，这一系数直接影响 T3 阶段"单工具 18 元上限"的判据计算。在 amoeba 模块的生产调用点为零（SaveDailyStats 与 AggregateDailyStats 全仓零调用点）的现状下，坪效判据改走 GET /autoops/billing?group_by=task|round 接口，源表为 token_billing_records（现库约 2,583 行覆盖 13 个项目），"单工具"成本须自行按 task_id 与工具的映射关系进行归因。

三、预置条件与环境配置

3.1 项目与预算配置

C5 场景使用专用项目 lts_c5_tools（实际项目 ID 以创建时生成为准，T1-D1 中使用的是项目 1117 lts_c5_toolforge_1790227852226_5150），归属于公司 LTS-C5 网页AI工具矩阵（公司 976）。项目的核心配置参数如下：

配置项	值	说明
运行模式	全自动（full_auto）	AI 自主拆解轮次、双引擎执行、审批与人在回路
总预算	10,000 元	平台侧 project_budgets.total_budget
AI 运行预算	3,500 元	project_config.ai_budget，宿主 budget_states.ai_budget
single_round_max_budget	6 元	单轮预算上限，超限暂停整个项目
review_every_rounds	6	每 6 轮触发一次 review 重排
parallel_enabled	true	启用并行任务执行
max_parallel	6	最大并行任务数
max_exec_sec	7200	单任务最大执行时间（秒）
预警线	80%	budget_states.warn_percent，触发预警通知

需要特别注意的是，轮次间隔（tick interval）在实测中约为 63-68 秒，而 project_config.default_interval_sec 的值为 30，tick_interval_sec 为 0——这两个控件实际上未被引擎装配（ISSUE-W4-44 记录），引擎硬编码使用 60 秒间隔（engine.go:52、:875）。加上每轮执行时间，实际轮次节奏约为每轮 60-110 秒墙钟时间。

3.2 壳 + 3 工具选题清单

项目启动时需要预置一套共用工具壳与首批 3 个工具的选题定义。壳（shell）包含统一的用户界面框架、埋点系统、登录/支付模块、跨工具推荐位等公共组件。首批 3 个工具选题如下：

编号	工具名称	类型	目标关键词（示例）	任务权重
T1	JSON 格式化器	开发者工具	json formatter, json beautifier	3（最高）
T2	图片压缩器	媒体工具	image compressor, reduce image size	2
T3	二维码生成器	营销工具	qr code generator, free qr code	1

T1-D1 实际创建了 6 条任务（T1-T6），权重分别为 3/2/1/1/2/1，包含 1 条 P0 优先级、1 条 P3 优先级和 1 条 loop 建页任务。这 6 条任务在 68 轮调度中产生了 57 个任务轮和 11 个 review 轮，总成本约 1.12 元。

3.3 知识库预置

为防止 AI 重复造轮或互相覆盖，需要在项目知识库中预置以下文档：

• 壳规范文档：定义共用外壳的组件清单、样式规范、埋点接口、部署清单，确保所有工具使用统一的技术栈和接口标准。
• 已建工具索引：记录每个已建工具的 URL、技术实现、关键词分配，避免新建工具与已有工具产生功能重叠或 SEO 内耗。
• SEO 规范：标题模板、meta 描述规范、内链策略、sitemap 格式要求。
• 组件清单：可复用的 UI 组件（代码高亮、文件上传、进度条等）及其 API 文档。

注意：T1-D1 实测中 knowledge_documents=0，即知识库未被写入任何内容。这属于"未做写入动作"的测试纪律约束，不代表产品能力缺失。在正式测试中，应在引导流阶段或首轮调度前完成知识库预置。

3.4 FIX 修复项影响

C5 场景受多个 FIX 修复项状态影响，以下逐项说明其对测试判定的具体影响：

FIX	内容	对 C5 的影响	降级方案
FIX-003	预算联动断	本卡最致命：30 任务抢预算时若不联动，无法验证"熔断不饿死在建工具"	人工每 20 轮核 /autoops/billing 并手工暂停超额任务（记为干预）
FIX-004	扩编调度断	T2 扩编后新角色可能不被调度	扩编后手工绑任务，T2 复测点
FIX-001	通知断	审批推送延迟	轮询 /autoops/human-tasks + 定时脚本拉单
FIX-002	X 接线断	导流帖只能 pending_review	脉冲流量事件改为人工注入
FIX-006	计费明细页缺	单工具成本与坪效靠 SQL 手算，T3 淘汰机制的主要证据瓶颈	amoeba + psql 手算替代
FIX-007	云开通 UI	多站点部署	复用 mail1 增量目录，多站点用子路径

四、T1 生存期操作指引（1-3 轮 / 3 工具上线且被收录）

4.1 UI 操作路径

T1 生存期的完整 UI 操作路径如下，每一步都需要截图取证：

1. 登录：访问 http://localhost:5176/login，使用 lts_c5_* 前缀账号登录（密码 test123）。
2. 全局面板：登录后自动跳转到 /dashboard，确认可自定义展示模块。
3. 建公司：点击"新建公司"，名称填 LTS-C5 网页AI工具矩阵，行业选"工具站矩阵"。
4. 建项目：在公司详情页新建项目 lts_c5_tools，运行模式选"全自动"，总预算填 10000，AI 运行预算填 3500。
5. 引导流：进入项目引导流（4 步）：业务介绍（批量工具站 SEO 变现）→ 组织（1 人 + 2 AI：全栈、内容）→ 定义（3 工具选题）→ 启动。
6. 录入服务器：在实例管理页录入 127.0.0.1:8090，等待 grant 下发、自检通过、状态变为 running。
7. autoops 面板起任务组：进入 /project/:id/autoops，在任务管理页创建 6 条任务（关键词矩阵/壳规范/sitemap/坪效核算/导流文案/loop 建页），设置权重与优先级。
8. 启动引擎：点击"启动"按钮，观察轮次开始自动 tick。

4.2 核心观察

每轮被选中任务分布

在 autoops 面板的轮次视图中，观察每一轮被选中的任务 ID 与对应引擎类型（loop/agent）。重点关注：

• 权重为 3 的任务（T1 关键词矩阵）是否获得最多的执行机会
• 权重为 1 的任务（T3/T4）是否被不公平地边缘化
• 轮次模式（task/review/free）的切换是否符合 review_every_rounds=6 的配置

通过 psql 实时查询 auto_ops_rounds 表获取精确数据：

SELECT round_no, mode, task_id, engine, cost, created_at
FROM auto_ops_rounds
WHERE project_id = '1117'
ORDER BY round_no DESC
LIMIT 20;

free 维护不误停在建任务

当所有待办任务处理完毕后，系统进入 free 维护模式。此时需要验证：

• auto_ops_tasks 中未完成任务集不变（不被误标为完成或取消）
• free 轮次不产生计费（或仅产生极少的空转计费）
• free_round_count 正常增长

注意：T1-D1 中 C5-7（free 维护首验）因脚本窗口口径缺陷未能正确判定，该判据在战役内"从未真判"。正式测试时需要在冷启动新槽的 0 任务窗口进行验证。

4.3 事件注入

T1 阶段需要注入以下外部事件（节奏：每 3 天 1 组），使用 harness/ingest-event.mjs 脚本或直接调用 POST /api/v1/events 接口（需 HMAC 三头认证）：

事件 1：GSC 收录周报

{
  "source": "gsc",
  "event_type": "seo.weekly",
  "title": "GSC 收录周报",
  "content": "{\"pages_indexed\":12,\"impressions\":340,\"ctr\":0.021,\"top_queries\":[\"json formatter online\",\"format json tool\"]}",
  "priority": "normal",
  "project_id": "1117"
}

期望反应：收录数据入库 → 驱动内容优化任务（如针对高曝光低 CTR 的关键词优化标题）。

事件 2：首个广告收益

{
  "source": "adsense",
  "event_type": "adsense.earning",
  "title": "首个广告收益 $1.20",
  "content": "{\"amount\":1.20,\"currency\":\"USD\",\"period\":\"2026-09-20 to 2026-09-26\",\"tool\":\"json-fmt\"}",
  "priority": "normal",
  "project_id": "1117"
}

期望反应：收益入账 project_ledger（income/revenue 科目）→ 驱动坪效核算任务更新。

事件 3：用户 Bug 邮件

{
  "source": "email",
  "event_type": "user.bug",
  "title": "用户反馈：JSON 格式化器无法处理超大文件",
  "content": "{\"tool\":\"json-fmt\",\"issue\":\"超过 10MB 的 JSON 文件导致浏览器卡死\",\"user_agent\":\"Chrome/120\",\"severity\":\"medium\"}",
  "priority": "important",
  "project_id": "1117"
}

期望反应：Bug 转返工任务 → 验收 Agent 对照 done_when 验收修复结果。

4.4 人工动作

T1 阶段需要完成以下人工动作（全部计入干预次数）：

序号	动作	通道	核实要点
1	批准 3 次发布	deploy 审批弹窗	无敏感数据外泄、埋点代码存在、页面可访问
2	批准 6 篇导流文案外发	connector_audit_logs 审批	无绝对化用语、含退订信息、署名 ZY Pan
3	确认 1 次任务优先级	autoops 面板	AI 建议与人的判断冲突时记录理由到 decision_traces

所有人工审批动作应当通过 UI 真实路径完成（点击"批准"/"驳回"按钮），而非直接操作数据库。审批延迟（FIX-001 待 e2e 验证前）通过轮询 /autoops/human-tasks 接口兜底，审批时效记为观察项。

4.5 调度公平性断言方法

调度公平性的断言是本场景最核心的取证工作。由于"调度可观测面板"（P0 建议项）尚未落地，目前依赖 psql 离线计算。以下是完整的断言方法：

方法一：同权重实得轮数比

-- 按任务统计被选中次数，按权重分组对比
SELECT t.id, t.name, t.weight, t.priority,
       COUNT(r.id) AS selected_count,
       t.round_count
FROM auto_ops_tasks t
LEFT JOIN auto_ops_rounds r ON r.task_id = t.id AND r.mode = 'task'
WHERE t.project_id = '1117' AND t.status != 'cancelled'
GROUP BY t.id, t.name, t.weight, t.priority, t.round_count
ORDER BY t.weight DESC, selected_count DESC;

判定标准：同权重任务的 selected_count 差异不应超过 2 倍。T1-D1 实测同权重（w=1）差异达 4.7 倍（3 vs 14），判定为红。

方法二：饿死判定（连续 N 轮未选中）

-- 计算每个任务的最长连续未选中轮数
-- 思路：生成完整轮次序列，左连接任务选中记录，找最长空白段
WITH all_rounds AS (
  SELECT round_no FROM auto_ops_rounds
  WHERE project_id = '1117' AND mode = 'task'
  ORDER BY round_no
),
task_rounds AS (
  SELECT r.round_no, r.task_id
  FROM auto_ops_rounds r
  WHERE r.project_id = '1117' AND r.mode = 'task'
)
-- 对每个任务，计算其未被选中的连续轮次数
-- 具体实现需按任务逐一计算，或使用窗口函数 LAG/LEAD
-- 简化版：统计每个任务在总轮次中的缺席率
SELECT t.name, t.weight,
  (SELECT COUNT(*) FROM all_rounds) AS total_task_rounds,
  COUNT(r.task_id) AS present_rounds,
  (SELECT COUNT(*) FROM all_rounds) - COUNT(r.task_id) AS absent_rounds
FROM auto_ops_tasks t
LEFT JOIN task_rounds r ON r.task_id = t.id
WHERE t.project_id = '1117'
GROUP BY t.id, t.name, t.weight
ORDER BY absent_rounds DESC;

判定标准：任何任务连续 5 轮未被选中即为饿死。T2 阶段将此作为"王牌断言"——做不到即失败。

方法三：时间窗重叠检测

-- 检测并行任务是否存在时间窗重叠
SELECT a.round_no AS round_a, b.round_no AS round_b,
       a.task_id AS task_a, b.task_id AS task_b,
       a.started_at, a.finished_at,
       b.started_at, b.finished_at
FROM auto_ops_rounds a
JOIN auto_ops_rounds b ON a.round_no < b.round_no
  AND a.project_id = b.project_id
  AND a.mode = 'task' AND b.mode = 'task'
WHERE a.finished_at IS NULL OR b.started_at IS NULL
   OR (a.started_at < b.finished_at AND b.started_at < a.finished_at)
LIMIT 20;

T1-D1 实测中 parallel_enabled=true/max_parallel=6 但时间窗重叠对数为 0，说明并行控件实际未被消费者使用（ISSUE-W4-44），任务实际为串行交替执行。

五、T2 扩张期操作指引（4-10 轮 / 15 工具在跑）

T2 扩张期是 C5 场景的核心压测阶段。工具数量从 3 个扩展到 15 个，任务队列显著增长，调度公平性面临真正的压力。此阶段的核心目标是验证：在 15 个工具并行运营的情况下，调度器不会饿死任何任务，且 review 轮的重排机制能够根据业务数据动态调整资源分配。

5.1 流量脉冲注入

T2 阶段需要模拟来自 Hacker News、Reddit、目录站等渠道的流量脉冲事件，验证系统能否自动识别高流量工具并为其加预算与内链。

{
  "source": "hn",
  "event_type": "traffic.pulse",
  "title": "HN 首页脉冲",
  "content": "{\"tool\":\"json-fmt\",\"pv\":2100,\"ref\":\"https://news.ycombinator.com/item?id=12345\",\"duration_hours\":6}",
  "priority": "important",
  "project_id": "1117"
}
{
  "source": "reddit",
  "event_type": "traffic.pulse",
  "title": "Reddit r/webdev 推荐",
  "content": "{\"tool\":\"img-compress\",\"pv\":850,\"ref\":\"https://reddit.com/r/webdev/comments/xxx\",\"duration_hours\":12}",
  "priority": "normal",
  "project_id": "1117"
}
{
  "source": "email",
  "event_type": "backlink.cooperation",
  "title": "外链合作邮件：tool_directory.io",
  "content": "{\"from\":\"editor@tooldirectory.io\",\"offer\":\"featured listing\",\"cost\":\"free\",\"tool_category\":\"developer-tools\"}",
  "priority": "normal",
  "project_id": "1117"
}
{
  "source": "google",
  "event_type": "algorithm.update",
  "title": "Google 核心算法更新",
  "content": "{\"update_name\":\"2026-09 Core Update\",\"impact\":\"content quality signals boosted\",\"affected_tools\":\"all\"}",
  "priority": "important",
  "project_id": "1117"
}

注入节奏：每周 1-2 次脉冲事件。期望反应：高流量工具（如 json-fmt 获得 2100 PV）应自动获得更多调度权重和内链资源；外链合作邮件走审批流程（黄通道）；算法更新公告触发全站内容质量检查任务。

5.2 review 轮重排

每 6 轮自动触发一次 review 模式。在 T2 阶段，review 轮应当根据注入的流量数据和收益数据，对任务权重进行动态调整：

• 砍低 RPM 工具：如果某个工具的 RPM（每千次展示收入）持续低于阈值，review 轮应降低其调度权重或将其标记为"待淘汰"。
• 加注高留存工具：流量高且用户停留时间长的工具应获得更多算力投入（增加权重、分配更多 Agent 资源）。
• 组合 RPM 上行：重排后，整个工具组合的加权平均 RPM 应当呈上升趋势——这是 review 机制有效性的核心判据。

验证 review 重排是否生效的方法：

-- 检查 review 轮记录与 last_review_round 前进
SELECT mode, COUNT(*) AS cnt,
       MIN(round_no) AS first_round, MAX(round_no) AS last_round
FROM auto_ops_rounds
WHERE project_id = '1117'
GROUP BY mode;

-- 检查槽位表三次采样，确认布局变化
SELECT * FROM auto_ops_schedules
WHERE project_id = '1117'
ORDER BY updated_at DESC;

-- 检查 last_review_round 是否持续前进
SELECT last_review_round, review_every_rounds, review_fail_count
FROM auto_ops_meta
WHERE project_id = '1117';

5.3 扩编与饿死判定

T2 阶段需要按队列积压情况提出扩编建议并执行。预期扩编 +2 前端 +1 SEO，共 3 个新岗位。扩编后必须验证新角色是否在 3 轮内被调度器纳入执行花名册——这是 FIX-004 的关键复测点。

-- 验证新角色是否被调度（FIX-004 复测）
SELECT r.role_id, a.name AS role_name, COUNT(*) AS rounds_count
FROM auto_ops_rounds r
JOIN agents a ON a.id = r.role_id
WHERE r.project_id = '1117'
  AND r.created_at >= '扩编时间戳'
GROUP BY r.role_id, a.name
ORDER BY rounds_count DESC;

饿死判定的完整方法（T2 王牌断言）：

T2 阶段还需要处理一次预算预警追加 1,500 元的场景：当 budget_states.ai_used 达到 ai_budget * warn_percent（即 3500 * 0.8 = 2800 元）时，系统应发出预警通知。人工在 UI 预算明细弹窗中批准追加预算，验证 budget_alerts 表新增行与面板黄色进度条变化。

此外，T2 阶段需要批准 1 次砍掉已建工具的决策（沉没成本决策）——这是验证系统能否理性放弃低效工具的关键场景。被砍工具的 deploy 状态应标记为 archived，其调度槽位被释放给其他任务。

六、T3 规模化期操作指引（11-30 轮 / 30 工具 + 长尾淘汰）

T3 规模化期将工具数量扩展到 30 个，同时引入长尾淘汰机制、并发冲突仲裁和异常处置流程。此阶段的核心挑战是：在 30+ 任务并发争用资源的情况下，系统能否保持调度的稳定性、公平性和可观测性。

6.1 并发写冲突仲裁

当任务队列达到 30+ 时，多个任务可能同时修改同一个仓库文件（如共用壳文件的样式表、公共组件库）。系统需要通过 arbitration_cases 表记录冲突仲裁过程，确保不会发生互相覆盖的情况。

注入并发写冲突事件的方法：在同一轮次中，让两个任务同时尝试修改同一个壳文件（如 shell/styles.css）。验证：

• arbitration_cases 表新增仲裁记录，包含冲突双方、冲突文件、仲裁结论
• decision_logs 留痕仲裁决策过程
• 最终文件内容只反映一方的修改（不出现内容混合或覆盖）
• 败方的修改被记录并可追溯

-- 检查仲裁记录
SELECT id, status, created_at, resolved_at
FROM arbitration_cases
WHERE project_id = '1117'
ORDER BY created_at DESC;

-- 检查决策日志
SELECT id, decision_type, content, created_at
FROM decision_logs
WHERE project_id = '1117'
ORDER BY created_at DESC;

6.2 Google 手动处罚 → 红通道冻结

T3 阶段需要模拟一次严重的 SEO 处罚事件——Google 发出手动处罚通知邮件。这是一个红通道事件，需要立即冻结对外发布并等待人工处理。

{
  "source": "google",
  "event_type": "penalty.manual",
  "title": "Google 手动处罚",
  "content": "{\"tool\":\"img-compress\",\"reason\":\"scaled pages\",\"action\":\"partial manual penalty\",\"affected_urls\":[\"https://tools.example.com/img-compress\"],\"appeal_deadline\":\"2026-10-10\"}",
  "priority": "urgent",
  "project_id": "1117"
}

期望反应链：

1. 系统识别 priority=urgent 的处罚事件，触发红通道流程
2. 冻结该工具的对外发布能力（connector_audit_logs 中该工具相关的写动作全部暂停）
3. 发送通知到飞书/邮件（notifications 表新增行 + 外发记录）
4. 创建人工审批节点（human_task_nodes），等待人工确认整改方案
5. 关键：其余 29 个工具的轮次调度照常运行，异常处置不牵连全矩阵

验证方法：在处罚事件注入后，观察其他工具的 auto_ops_rounds 是否继续正常产出，同时确认被处罚工具的 deploy 状态变为 frozen。

6.3 批量下架与回滚

T3 阶段需要批准 1 次批量下架 5 个低效工具的操作。下架操作需要满足以下条件：

• 下架清单必须附带证据（坪效数据、流量趋势、成本分析）
• 每个工具的下架操作支持一键回滚（/deploy/:id/rollback）
• 下架后相关调度槽位被释放，任务从队列中移除
• deploy_jobs 表记录下架操作，状态为 recalled

同时需要批准新域名与广告位接入（红/黄通道决策），以及批准阶段切换到 stage_3_scale。

T3 阶段的阈值要求：

指标	通过	观察	失败
自主率	≥78%	65-78%	<65%
人工升级	≤5 次/周	6-8 次/周	>8 次/周
单工具 token	≤18 元	≤22 元	>22 元
AI 成本/收入	<30%	30-40%	>40%
异常处置	不牵连全矩阵（其余工具轮次照常）= 通过；牵连 = 失败

七、验收判定表

以下为 C5 场景三阶段的综合验收判定表。判定采用三档制：通过（绿）、观察（黄）、失败（红）。

指标	T1 生存期	T2 扩张期	T3 规模化期
自主率（无人工动作即完成的轮次占比）	≥55% 通过 | 45-55% 观察 | <45% 失败	≥70%	≥78%
人工干预次数	≤12 次	≤8 次/周	≤5 次/周
单工具 token 成本	≤45 元	≤30 元	≤18 元
总预算偏差（Σ token_billing_records.cost vs 面板）	≤10%	≤10%（追加预算后）	≤10%
轮次死循环（同任务连续 3 轮失败无降级）	0 次	0 次	0 次
free 误停在建任务	0 次	0 次	0 次
饿死判定（无任务连续 5 轮未被选中）	观察项（T1 样本不足）	王牌断言：必须通过	持续通过
AI 成本/收入	—	<45%	<30%
异常处置不牵连全矩阵	—	—	必须通过

八、取证口径

C5 场景的取证采用"页面 + 网络 + psql"三重口径交叉验证，单层不定论。以下按取证对象分节说明。

8.1 auto_ops_rounds（轮次-任务矩阵）

这是 C5 场景最核心的证据表。每一轮调度都在此表留下记录，包含轮次号、模式（task/review/free）、选中任务 ID、引擎类型、成本等关键字段。

-- 轮次总账
SELECT mode, COUNT(*) AS cnt,
       ROUND(SUM(cost)::numeric, 4) AS total_cost,
       MIN(round_no) AS first_round,
       MAX(round_no) AS last_round
FROM auto_ops_rounds
WHERE project_id = '1117'
GROUP BY mode
ORDER BY mode;

-- 按引擎类型统计
SELECT engine, COUNT(*) AS cnt,
       ROUND(SUM(cost)::numeric, 4) AS total_cost,
       ROUND(AVG(cost)::numeric, 6) AS avg_cost_per_round
FROM auto_ops_rounds
WHERE project_id = '1117' AND mode = 'task'
GROUP BY engine;

-- 轮次-任务矩阵（完整视图）
SELECT round_no, mode, task_id, engine,
       cost, status, started_at, finished_at
FROM auto_ops_rounds
WHERE project_id = '1117'
ORDER BY round_no;

8.2 auto_ops_schedules（槽位权重）

槽位表记录了每个调度槽位的权重分配。通过在不同时间点采样槽位表，可以验证 review 轮是否真的改变了权重布局。

-- 槽位表完整视图
SELECT id, task_id, weight, priority, position,
       created_at, updated_at
FROM auto_ops_schedules
WHERE project_id = '1117'
ORDER BY position;

-- 配合 auto_ops_meta 的 last_review_round 确认重排时间线
SELECT run_count, task_run_count, last_review_round,
       review_every_rounds, review_fail_count,
       guard_paused, guard_pause_reason
FROM auto_ops_meta
WHERE project_id = '1117';

8.3 饿死统计 SQL

以下是计算每个任务最长连续未被选中轮数的完整 SQL。该查询采用"间隔检测"方法：对于每个任务，在其被选中的轮次之间寻找最大间隔。

-- 饿死统计：每个任务的最长连续未选中轮数
-- 方法：对每个任务，将其被选中的轮次号排序，计算相邻轮次号的差值
WITH task_rounds_ordered AS (
  SELECT task_id, round_no,
         ROW_NUMBER() OVER (PARTITION BY task_id ORDER BY round_no) AS rn
  FROM auto_ops_rounds
  WHERE project_id = '1117' AND mode = 'task'
),
gaps AS (
  SELECT a.task_id,
         a.round_no AS start_round,
         b.round_no AS end_round,
         b.round_no - a.round_no - 1 AS gap_size
  FROM task_rounds_ordered a
  JOIN task_rounds_ordered b ON a.task_id = b.task_id AND a.rn + 1 = b.rn
  WHERE b.round_no - a.round_no > 1
),
-- 还需要考虑首轮之前和末轮之后的空白
max_gaps AS (
  SELECT task_id, MAX(gap_size) AS max_consecutive_absent
  FROM gaps
  GROUP BY task_id
  UNION ALL
  -- 首轮之前的空白
  SELECT t.id, MIN(r.round_no) - 1 AS gap
  FROM auto_ops_tasks t
  LEFT JOIN auto_ops_rounds r ON r.task_id = t.id AND r.mode = 'task'
  WHERE t.project_id = '1117'
  GROUP BY t.id
  HAVING MIN(r.round_no) > 1
)
SELECT t.name, t.weight, t.priority,
       COALESCE(mg.max_consecutive_absent, 0) AS max_starvation_rounds,
       CASE WHEN COALESCE(mg.max_consecutive_absent, 0) >= 5
            THEN 'STARVED' ELSE 'OK' END AS status
FROM auto_ops_tasks t
LEFT JOIN (
  SELECT task_id, MAX(max_consecutive_absent) AS max_consecutive_absent
  FROM max_gaps
  GROUP BY task_id
) mg ON mg.task_id = t.id
WHERE t.project_id = '1117'
ORDER BY max_starvation_rounds DESC;

此外，以下 SQL 用于统计仲裁案例、预算状态和成本归因：

-- 仲裁案例统计
SELECT status, COUNT(*) FROM arbitration_cases
WHERE project_id = '1117' GROUP BY status;

-- 预算状态
SELECT ai_budget, ai_budget_used, warn_percent, warned, meltdown,
       updated_at
FROM budget_states
WHERE project_id = '1117';

-- 成本按任务归因（单工具成本）
SELECT t.name AS task_name,
       COUNT(r.id) AS round_count,
       ROUND(SUM(r.cost)::numeric, 4) AS total_cost
FROM auto_ops_tasks t
LEFT JOIN auto_ops_rounds r ON r.task_id = t.id AND r.mode = 'task'
WHERE t.project_id = '1117'
GROUP BY t.id, t.name
ORDER BY total_cost DESC;

九、附录：环境信息

9.1 端口映射

服务	地址	说明
PostgreSQL 17	localhost:5432	双库：ai_native_engine（平台）/ project_server（实例）
platform 后端	http://localhost:18000	公司/项目/实例/平台真实账本/计费结算/超管后台
project-server	http://localhost:8090	AI 执行引擎，当前实例绑定宿主项目
前端（vite dev）	http://localhost:5176	三端同机，playwright baseURL
WebSocket	ws://localhost:18000/ws?token=	通道在码但前端默认不发起；auto-ops 日志/轮次看板走每 3 秒轮询（#240 C 案，2026-09-29；WS 实时链路 A 批待裁）
出海代理	127.0.0.1:7890	新加坡 IP，用于外网访问

9.2 关键表清单

project_server 库（实例侧）

表名	用途	C5 相关度
auto_ops_tasks	任务定义（权重/优先级/状态）	核心
auto_ops_rounds	轮次执行记录	核心
auto_ops_schedules	调度槽位权重	核心
auto_ops_meta	引擎元数据（轮次计数/guard 状态）	核心
auto_ops_progress	任务进度	高
token_billing_records	token 计费明细	高
budget_states	预算状态（AI 已用/预警/熔断）	高
budget_alerts	预算预警记录	高
project_config	项目配置（预算/间隔/并行）	高
arbitration_cases	冲突仲裁记录	高
events	注入事件	高
acceptance_records	三权验收记录	中
human_task_nodes	RACI 人工节点	中
deploy_jobs	发布/回滚作业	中
knowledge_documents	知识库文档	中
notifications	站内通知	中
connector_audit_logs	连接器审计日志	中
decision_traces	决策追踪	中
project_ledger	项目虚拟账本	中
agents / org_charts	角色/组织	中
marketing_campaigns	营销活动	低
llm_call_logs	LLM 调用日志	低

ai_native_engine 库（平台侧）

表名	用途
companies	公司
projects	项目
project_budgets	项目预算（total_budget / used_amount）
instances	实例
platform_balances	平台余额
token_billing_reports	计费报告（status settled/duplicated）

9.3 harness 脚本用法

长周期运营 harness 位于 wiki/long_term_testing/harness/，使用 Node ESM（.mjs）编写，零第三方依赖（Node >= 20）。

drive.mjs — 推进/观察 auto-ops 一轮

cd wiki/long_term_testing/harness

# 观察轮：只读采集 + 快照 + 台账（零副作用）
node drive.mjs

# 触发 review，轮询等 auto_ops_rounds 最大 id 增长
node drive.mjs --mode review --wait 240

# 触发 AI 分析（真实 LLM 计费，谨慎）
node drive.mjs --mode analyze --analyze-type analysis

# 指定场景标签
node drive.mjs --scenario C5 --label "T2-D3"

ingest-event.mjs — 外部事件注入

# GSC 收录周报
node ingest-event.mjs --type seo.weekly --scenario C5 \
  --text '{"pages_indexed":12,"impressions":340,"ctr":0.021}'

# AdSense 收益
node ingest-event.mjs --type adsense.earning --scenario C5 \
  --text '{"amount":1.20,"currency":"USD"}'

# 流量脉冲
node ingest-event.mjs --type traffic.pulse --scenario C5 \
  --text '{"tool":"json-fmt","pv":2100}' --priority important

# Google 处罚（红通道）
node ingest-event.mjs --type penalty.manual --scenario C5 \
  --text '{"tool":"img-compress","reason":"scaled pages"}' --priority urgent

# 只落台账不投喂（降级模式）
node ingest-event.mjs --type payment --channel none --dry-run

# 续跑：重投未成功的事件
node ingest-event.mjs --replay-pending

approve.mjs — 审批模拟器

# 查看审批队列（零副作用）
node approve.mjs --dry-run

# 执行审批（按 approve-rules.json 规则自动判定）
node approve.mjs

# 指定队列 + 金额上限
node approve.mjs --scope human --max-amount 20 --limit 5

# 端到端自证
node approve.mjs --selftest

lib.mjs — 公共库自检

# 健康探测 + 取 token + 两库只读 + autoops 配置读
node lib.mjs

# 含外网代理探测
node lib.mjs --with-proxy

---

ZY AI Native Engine · 长周期业务场景测试 · C5 网页 AI 工具矩阵工厂 · 场景指引
版本：2026-10-07 · 基于 commit 锚 2d4aa14 · 以最新 git log 与代码为准
2026-10-07 同步（V3 API 回归战役，wiki/testing/v3/）：WS 实时链路未默认接线，日志/轮次改 3 秒轮询（#240 C 案）；缺项目作用域策略确认记录的存量项目启动 autoops 会被闸拦截，重走引导确认即解锁（V3-07 待裁回填）；其余操作路径与判定阈值经复核不变。